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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document defines the stage-2 description of the mechanism to provide the 3GPP network entities with UE 
Specific Behaviour Information (UESBI). UESBI may be used by correcting mechanisms to overcome some of the 
issues that have been recognized by 3GPP in TR 25.994 (Measures employed by the UMTS Radio Access Network 
(UTRAN) to overcome early User Equipment (UE) implementation faults) [13], and other such documents. The 
description of these correcting mechanisms is out of the scope of this TS. 

ITU-T Recommendation 1.130 [1] describes a three-stage method for characterisation of telecommunication services, 
and ITU-T Recommendation Q.65 [2] defines stage 2 of the method. 

Editor's note: some text within this TS is dependent on future GERAN and SA2 decisions, as described 
below: 

Text with this colour background (yellow?) in this TS is dependent upon a GERAN decision on whether 
the transfer of UESBI-Iu is applicable on the A interface. 

Text in Annex B should be moved to clause 6, which part to move is depends upon SA2's decision to 
select one or both of the solutions to map IMEIS V to UESBI-Iu 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] ITU-T Recommendations 1.130: "General modelling methods - Method for the characterisation of 
telecommunication services supported by an ISDN and network capabilities of an ISDN". 

[2] ITU-T Recommendation Q.65: "Methodology - Stage 2 of the method for the characterization of 

services supported by an ISDN". 

[3] 3GPP TS 24.008: "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3". 

[4] 3GPP TS 23.060: "General Packet Radio Service (GPRS) Service description; Stage 2". 

[5] 3GPP TS 23.009: "Handover procedures". 

[6] 3GPP TS 25.331: "Radio Resource Control (RRC) protocol specification". 

[7] 3GPP TS 44.018: "Mobile radio interface layer 3 specification; Radio Resource Control (RRC) 

protocol". 

[8] 3GPP TS 44.008: "Mobile radio interface layer 3 specification". 

[9] 3GPP TS 25.413: "UTRAN lu interface Radio Access Network Application Part (RANAP) 

signalling". 

[10] 3GPP TS 23.236: "Intra-domain connection of Radio Access Network (RAN) nodes to multiple 

Core Network (CN) nodes". 

[II] 3GPP TS 29.060: "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) 
across the Gn and Gp interface". 
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[12] 3GPP TS 23.1 16: "Super-Charger technical realization; Stage 2". 

[13] 3GPP TR 25.994: "Measures employed by the UMTS Radio Access Network (UTRAN) to 

overcome early User Equipment (UE) implementation faults". 

[14] 3GPP TR 25.995: "Measures employed by the UMTS Radio Access Network (RAN) to cater for 

legacy User Equipment (UE) which conforms to superseded versions of the RAN interface 
specification". 

[15] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TS 21.905 [15] and the following 
apply. 

PUESBINE Feature: is the functionality described by this TS. 

UE Specific Behaviour Information - Uu (UESBI-Uu): is information that is sent using Access Stratum signalling 
from the UE to the RAN. It can be used to derive some specific information about the UE's capabilities. 

UE Specific Behaviour Information - lu (UESBI-Iu): is information that is sent from the MSC and/or SGSN to the 
RAN that can be used to derive some specific information about the UE's capabilities. The UESBl-lu is a Bit Map of 
UE Faults derived from the IMEISV. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TS 21.905 [15] and the following apply: 

PUESBINE Provision of UE Specific Behaviour Information to Network Entities 

UE User Equipment 

UESBI UE Specific Behaviour Information 

UESBI-Uu UE Specific Behaviour Information - Uu 

UESBI-Iu UE Specific Behaviour Information - lu 



General description 



4.1 UESBI 

Due to the potential problems that may happen in the standard or in its implementation by different types of UE, it may 
be needed to transfer to the RAN "information on the specific behavior of particular sets of UE" with regard to some 
3GPP features. This aims at helping the infrastructure to handle UE(s) already in the field that are facing problems to 
support some 3GPP features. This "information on the specific behavior of particular sets of UE" is called UE Specific 
Behavior Information (UESBI). 

UESBI actually corresponds to 2 different sets of information: 

• UESBI-Uu which is sent from UE to RAN using signalling specified in the RRC protocol (TS 25.331 
[6]) 

• UESBI-Iu which is sent by CN to UTRAN over the lu interface and is derived from IMEISV retrieved 
by CN from UE. 

UESBI-Uu and UESBl-Iu may have a different nature, their coding is defined in RRC and RANAP respectively, and 
have different handling within the network. Whether or not UESBI-Uu or UESBl-lu is used to describe an inter- 
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operability issue will be determined on a case by case basis and all uses should be documented in TRs such as 25.994 
[13] and 25.995 [14]. As a result of this process, RAN nodes should not receive conflicting information in UESBI-Uu 
and UESBI-Iu. 

The SRNC uses both UESBI-Iu and UESBI-Uu to derive the specific behaviour of the UE. 



4.2 



UESBI-Uu 



UESBI-Uu information is sent: 



(at RRC connection establishment from idle mode) directly by UE to Serving RNC at RRC connection 
establishment 

(at SRNS relocation) from Serving RNC to Target RNC in the RRC: SRNS RELOCATION INFO 
message carried through CN during SRNS relocation in the RANAP: Source RNC to Target RNC 
Transparent Container IE. 

(at RRC connection establishment for an UE coming from another Radio Access Technology e.g. in 
case of 2G to 3G Hand-Over) from UE to Serving RNC via "Inter RAT Hand-Over" Information. This 
"Inter RAT Hand-Over Information" is sent to the source RAN (e.g. BSS), and at handover copied by 
the source RAN into a transparent container that is carried through the CN towards the Target RNC. 

(at RR connection establishment) the UE can directly send the "Inter RAT Handover Information" 
which contains the UESBI-Uu to the GERAN BSS. However, if control of GERAN BSS functions 
using the UESBI-Uu is needed, then new functionality will be required within the BSS to decode the 
ASN. 1 PER information contained in the Inter-RAT Handover Information IE. 



4.3 



UESBI-Iu 



When the UE attaches to the VLR or SGSN or makes its first Location Update in the VLR, the IMEISV information is 
retrieved from the UE and stored in the VLR or SGSN. 

At each subsequent lu interface connection establishment (eg for a CS domain voice call or a PS domain data transfer), 
the IMEISV is retrieved from the VLR or from the MM context in the SGSN and, the UESBI-Iu is derived. The 
UESBI-Iu is then sent to the SRNC. The UESBI-Iu is normally sent in the Common Id procedure (the same procedure 
that currently carries the IMSI) or by the UESBI-Iu Information procedure. This is summarised in figure 4.3-1. 
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Figure 4.3-1 : UESBI-Iu architecture 

If the UE state is changed from RRC Connected to RRC Idle, all information derived from the received UESBI is 
released in the RNS. Thus if the UE state is changed afterwards back to RRC Connected the delivery of the UESBI-Iu 
from MSC or SGSN to SRNC shall be repeated. 

At inter-SRNS relocation or at inter-system handover, the anchor MSC (and not the source RAN node) sends the 
UESBI-Iu to the target RAN node. 
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4.4 



UESBI-lu on A interface 



With GERAN, usage of UESBI is currently aimed to only solve issues related to CS domain GERAN to UTRAN 
handover. To smooth rollout of features, a Handover Reject cause is defined to provide minimal functionality (see 
clause 5. 1.4.2). 

[Whether transfer of the UESBI-Iu to the BSS is needed to permit more sophisticated functionality is not certain. 
Signalling flows in this TS do however show how UESBI-Iu can be delivered to the GERAN BSS across the A 
interface. 

It is anticipated that the need for the BSS to use UESBI-Iu is less than that for the RNC. Hence, the standards shall 
ensure that it is an implementation choice as to whether or not to transfer UESBI-Iu across the A interface. ] 

Note: Currently no study has been performed on any need to influence the GPRS Cell Change Order to UTRAN 
procedure. 



5 Signalling flows 

5.1 UESBI-Uu signalling flows 



5.1 .1 RRC connection establishment (initial and at cell reselection towards 
UTRAN) 

At RRC connection establishment from idle mode, UESBI-Uu information shall be sent directly by the UE to the 
Serving RNC. This is valid both for the cases where the UE initiates the contact with the network either from RRC idle 
mode or in the case of a cell reselection from GERAN to UTRAN. 



UE 



UTRAN 



RRC connection establishment 



procedure (UESBI-Uu) 

Figure 5.1 .1-1 : UESBI-Uu transfer at RRC Connection Establishment 

The RRC Connection Establishment procedure is defined in TS 25.331 [6] 

5.1 .2 RR connection establishment 



UE 



Source BSS 



UTRAN classmark [ 

INTER RAT HANDOVER 

mBQ-\ 



(sent via other RAT) 



Figure 5.1.2-1 : UESBI-Uu transfer at RR Connection Establishment 

The UE sends the "Inter RAT Handover Information" which contains the UESBI-Uu to the GERAN BSS. Whether this 
information is sent immediately at RR connection establishment or this is delayed until just before inter-RAT handover 
is performed, is controlled by the BSS. Further information is given in TS 25.331 [6] and TS 44.018 [7]. 
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5.1.3 SRNS relocation 

UESBI-Uu information is sent from the Serving RNC to the Target RNC in the RRC: SRNS RELOCATION INFO 
message (specified in 25.331 [6]) which is carried through the CN during SRNS relocation in the RANAP: Source RNC 
to Target RNC Transparent Container IE ([9]). 

This transparent container is: 

• put in the RANAP Relocation Required message sent by the Serving RNC to the CN, 

• carried from source MSC/SGSN to target MSC/SGSN via E or Gn interface signalling in the case of inter 
MSC/SGSN SRNS relocation 

• sent by the target MSC/SGSN in the RANAP Relocation Request message sent to target RNC. 

5.1 .4 Inter RAT hand-over 



5.1.4.1 



3G -^ 2G inter-RAT hand-over 



If the UE fails to support properly this kind of Hand-Over, UTRAN can detect it through UESBI information already 
received from UE or CN, and react accordingly (e.g. avoid this kind of Hand-Over,. . . ). 

5.1 .4.2 2G -^ 3G inter-RAT hand-over 

UESBI-Uu information is sent from UE to Serving RNC via "Inter RAT Hand-Over" Information transfer. 



UE 



Source BSS 



CN 



HO required [ INTER 
RAT HANDOVER INFO 1 



RNC 



Relocation Request 

[ INTER RAT 
HANDOVER INFO 1 



UTRAN classmark 

[ INTER RAT 
HANDOVER INFO] 



Figure 5.1.4.2-1 UESBI-Uu transfer at inter-RAT handover 

The inter RAT handover information transfer procedure is used by the UE to convey RRC information needed for inter 
RAT handover to UTRAN. "Inter RAT Hand-Over Information" is prepared by the UE, then sent on the Radio 
Resource (RR) layer of the source RAT (e.g. RR for GSM) together with Radio classmark information. Further 
information is given in TS 25.331 [6] and TS 44.018 [7]. 

At 2G -^ 3G hand-over / SRNS relocation this information is transferred from source BSS to target RNC through the 
CN via the relevant BSS to RNC transparent containers defined in 48.008 [8] and 25.413 [9]. 

The target RNC shall use the UESBI-Uu to determine whether the handover can succeed. 

In the case that the target RNC believes that the handover can succeed, the target RNC may use the UESBI-Uu to aid 
the handover procedure. 

In the case that the UESBI-Uu indicates to the target RNC that the handover will fail, the target RNC shall reject the 
handover attempt. The target RNC shall use a specific cause value that causes the source BSS to not attempt further 2G 
to 3G handovers for that UE, and, causes the source BSS to take appropriate actions, eg to modify the set of 
neighbouring cells that the UE is measuring. 

This requires that the GSM BSS shall include the Response Request IE in the Handover Required message. 

Following an inter-BSS handover, the new BSS might attempt a GSM to UMTS handover that is doomed to failure. To 
avoid this the old BSS shall indicate to the new BSS whether or not the UE has had a handover to UMTS rejected by an 
RNC "because of the UESBI". 
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5.2 UESBI-lu signalling flows 

5.2.1 CS attach / normal location update without Gs 

5.2.1.1 Obtaining the IMEISV 

In order for the UESBI-Iu functionality to perform satisfactorily, the CS domain shall indicate that IMSI Attach-Detach 
shall be applied in both 2G and 3G cells. 

When the UE sends a Location Updating Request message to the MSC/VLR, then: 

a) if the Location Updating Type is set to "IMSI attach", the MSCA'LR shall obtain the IMEISV from the UE ; 

b) if the Location Updating Type is set to "Periodic updating", the MSC/VLR need not obtain the IMEISV from the 
UE; 

c) if the Location Updating Type is set to "Normal Location Updating" then the MSC/VLR should obtain the IMEISV 
from the UE. 

For case (c) above, the MSC/VLR shall obtain the IMEISV if the IMSI was not previously registered in the VLR. 
Optimisation of the MSC/VLR behaviour for case (c) is permitted in order to balance the signaling load caused by 
obtaining the IMEISV at every intra-MSC normal location update against the chances that the MSC/VLR does not 
discover IMEISV changes caused by the SIM being inserted into a new UE which then Location Updates to a new LA 
within the same MSC/VLR. 

Note 1 : If any mismatch between the UE's IMEISV and the IMEISV stored in the MSC/VLR leads to the user 

having problems, then the problems may be cleared by the user switching the UE off and back on, forcing 
a CS domain IMSI Attach to occur. 

Note 2: any such optimisations should be re-evaluated if the Supercharger (see TS 23.116 [12]) or Intra Domain 
Connection of RAN Nodes to Multiple CN nodes ("lu-flex", TS 23.236 [10]) features are implemented in 
the MSC/VLR. 

The MSC/VLR can obtain the IMEISV by either the MM Identification Procedure defined in TS 24.008 [3] or by using 
the Cipher Mode Control procedure defined in TS 48.008 [8]. 

5.2.1 .2 Transfer of UESBI-lu to RAN 

Editor's note: A message flow diagram should be added here. 

Because of potential UE problems with the Security procedures, the MSC/VLR shall send the UESBI-Iu information to 
the RNC before sending the RANAP Security Mode Command message to the RNC. 

[If the UESBI-Iu transfer is supported on the A interface, then the MSC/VLR should send UESBI-Iu as soon as 
possible (eg to permit the BSS to modify its interpretation of the Measurement Reports sent by the UE).] 

5.2.2 PS attach without Gs 

The procedure can be derived from clause 5.2.3, Combined PS and CS attach with Gs, by omitting the signalling via the 
Gs interface and the CS domain internal signalling (steps 8a - 8h, 8i and 1 1). 

5.2.3 Combined PS and CS attach with Gs 

The Combined GPRS / IMSI Attach procedure is illustrated in Figure 5.2.3-1 (copied from 3GPP TS 23.060 [4]). 
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Figure 5.2.3-1 : Combined GPRS / IIUISI attacli procedure 

1-4) Steps 1-3 are as described in TS 23.060 [4]. 

4a,b,c)The equipment checking functions are defined in the clause "Identity Check Procedures" in 23.060 [4]. The 
SGSN shall obtain and store the IMEISV. Equipment checking with the EIR is optional. 

The SGSN can use either the GMM Identification procedure or the GMM Authentication and Ciphering 
procedure to obtain the IMEISV (see TS 24.008 [3]). 
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If the GMM Identification procedure is used to obtain the IMEIS V (and the GMM Identification Request is sent 
before the GMM Authentication and Ciphering Request message), then it depends upon the SGSN 
implementation as to whether the UESBI-Iu information is sent to the RNC before or after the GMM 
Authentication and Ciphering Request message. 

4d, 5) The SGSN shall send the UESBI-Iu information to the RNC before sending the RANAP Security Mode 
Command message to the RNC. 

If the RNC does not receive the UESBI-Iu information before the RANAP Security Mode Command, then the 
RNC should assume that no UESBI-Iu information is available for this UE (for example, because the SGSN does 
not support the PUESBINE Feature). 

6-7) Steps 6 and 7 are as described in TS 23.060 [4]. 

8a) The SGSN shall send the IMEISV to the MSC in the Gs interface Location Update Request message. 

If the MSC does not receive the IMEISV in Gs interface Location Update Request message (eg because the 
SGSN does not support the PUESBINE Feature) then the MSC shall obtain the IMEISV from the UE at the next 
lu-cs or A interface connection establishment. 

8) Steps 8b to 8h are as described in TS 23.060 [4]. 

9-11) Steps 9 to 11 are as described in TS 23.060 [4]. 

5.2.4 PS inter-SGSN routeing area update without Gs 

The IMEISV shall be transferred from the old SGSN to the new SGSN at inter-SGSN Routeing Area Update in the 
SGSN Context Response message (see TS 29.060 [11]). GTPvl is assumed to be available in both SGSNs. The new 
SGSN shall transfer the UESBI-Iu to the RNC over the lu-ps interface. 

In the case of inter-SGSN RA Update from an SGSN not supporting the PUESBINE Feature to an SGSN that does 
support the PUESBINE Feature, then, the new SGSN shall obtain the IMEISV from the mobile using signalling 
specified in TS 24.008 [3] and then send the UESBI-Iu to the RNC. 
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5.2.5 Inter-SGSN routeing area update with Gs 

The Combined RA / LA Update (inter-SGSN) procedure is illustrated in Figure 5.2.5-1 (copied from 3GPP TS 23.060 

[4]). 
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Figure 5.2.5-1 : Combined RA / LA update in the case of inter-SGSN RA ppdate procedure 
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1) The MS sends a Routeing Area Update Request to the new SGSN (see TS 23.060 [4]). 

2) The new SGSN sends SGSN Context Request to the old SGSN and the old SGSN returns the SGSN Context 
Response message (see TS 23.060 [4]). 

The IMEISV shall be sent by the old SGSN to the new SGSN at inter-SGSN Routeing Area Update in the SGSN 
Context Response message (see TS 29.060 [11]). GTPvl is assumed to be available in both SGSNs. 

The new SGSN derives the UESBI-Iu from the IMEISV. 

If the new SGSN does not receive the IMEISV from the old SGSN (eg because the old SGSN does not support 
the PUESBINE Feature) then the new SGSN shall use GMM signalling to obtain the IMEISV from the UE. 

3a, b, c) The new SGSN shall transfer the UESBI-Iu to the RNC over the lu interface, and, perform 
authentication. The order of 3a and 3b is dependent upon the implementation of the SGSN. 

The SGSN shall send the UESBI-Iu information to the RNC before sending the RANAP Security Mode 
Command message to the RNC. 

If the RNC does not receive the UESBI-Iu information before the RANAP Security Mode Command, then the 
RNC should assume that no UESBI-Iu information is available for this UE (for example, because the SGSN does 
not support the PUESBINE Feature) (unless, in the case of non-combined RA update, the RNC has already 
received UESBI-Iu from the lu-cs interface). 

4 -10) Steps 4 to 10 are as described in TS 23.060 [4]. 

11) The SGSN shall send the IMEISV to the MSC in the Gs interface Location Update Request message. 

If the MSC does not receive the IMEISV in Gs interface Location Update Request message (eg because the 
SGSN does not support the PUESBINE Feature) then the MSC shall obtain the IMEISV from the UE at the next 
lu-cs or A interface connection establishment. 

12-16) Steps 12 to 16 are as described in TS 23.060 [4]. 

5.2.6 CS attach when already PS attached and Gs present 

The procedure described in 5.2.5 is applicable (in most cases without the SGSN change). Whether the MSC changes or 
not, the SGSN shall send the IMEISV to the MSC in the Gs interface Location Update Request message. 

5.2.7 CS domain, transfer of UESBI-Iu to RAN 

5.2.7.1 MS Initiated lu-cs [and A Interface ]Connection Establishment Procedure 

[This clause describes how this functionality can be made to operate on both the lu-cs and A interfaces.] 
[Note: it is an implementation choice as to whether or not to transfer UESBI-Iu across the A interface. ] 
[ 
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Figure 5.2.7.1-1 : MS initiated call in GSM 
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Figure 5.2.7.1-2: MS initiated call in UMTS 

1) [In GSM, the UE establishes an RR connection by sending the first MM message (eg CM Service Request) to 
the BSS.] 

In UMTS, the UE establishes an RRC connection (assuming that one does not already exist for PS services). 

2) [In GSM the BSS sends the first MM message to the MSC] 

In UMTS, the UE sends the first MM message (eg CM Sei-vice Request) to the MSC. 

3) In UMTS, the MSC shall send the UESBI-Iu to the RNC. 

[In GSM, if the MSC supports the transmission of the UESBI-Iu on the A interface, then the UESBI-Iu is sent to 
the BSS.] 

The authentication procedure (if it is to be performed) can be done before or after sending the UESBI-Iu to the 
[BSS/] RNC. 

4) In UMTS, the lu Security Mode command is performed. 

[In GSM, either the ciphering mode command is performed or a CM Service Accept message is sent to the 
mobile.] 

If the RNC[/BSS] does not receive the UESBI-Iu information before the RANAP Security Mode 
Command[/BSSMAP Cipher Mode Command], then the RNC[/BSS] should assume that no UESBI-Iu 
information is available for this UE (for example, because the MSC does not support the PUESBINE Feature) 
(and unless the RNC has already received UESBI-Iu on an existing PS domain lu connection). 
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5) The first CM layer message (eg Setup or Register) is sent by the UE to the MSC. 

5.2.7.2 Network Initiated lu-cs[ and A interface] Connection Establishment 

[This clause describes how this functionality can be made to operate on both the lu-cs and A interfaces.] 
[ 
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Figure 5.2.7.2-1 : Network initiated A Interface connection establishment (GSM)] 
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Figure 5.2.7.2-2: Network initiated lu-cs Interface connection establishment 

1) The MSC receives some stimulus that causes it to page the [BSS/]RNC. The [BSS/]RNC then pages the mobile. 

2) [In GSM, the UE sends the Paging Response to the BSS and the RR connection is established.] 

In UMTS, the UE establishes the RRC Connection (assuming that one does not already exist for PS services) 

3) [In GSM, the BSS sends the Paging Response message to the MSC] 
In UMTS, the UE sends the Paging Response message to the MSC. 

4) In UMTS, the MSC shaU send the UESBI-lu to the RNC. 

[In GSM, if the MSC supports the PUESBINE Feature on the A interface, then the UESBI-lu is sent to the BSS.] 
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The authentication procedure (if it is to be performed) can be done before or after sending the UESBI-Iu 
information to the [BSS/JRNC. 

5) The lu Security mode [or A interface Ciphering Mode] command is performed. 

If the RNC[/BSS] does not receive the UESBI-Iu information before the RANAP Security Mode 
Command[/BSSMAP Cipher Mode Command], then the RNC[/BSS] should assume that no UESBI-Iu 
information is available for this UE (for example, because the MSC does not support the PUESBINE Feature) 
(and unless the RNC has already received UESBI-Iu on an existing PS domain lu connection). 

6) Typically the first CM layer message (eg Setup or Register) is sent by the MSC to the UE. 

5.2.8 PS domain transfer of UESBI-Iu to RNC 
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Figure 5.2.8.1-1: MS Initiated Service Request Procedure 

1) The MS establishes an RRC connection (assuming that none exists for CS traffic). 

2) The MS sends a Service Request (P-TMSI, RAI, CKSN, Service Type) message to the SGSN. Service Type 
specifies the requested service. Service Type indicates one of the following: Data or Signalling. 

3a, b) The SGSN shall send the UESBI-Iu to the RNC before the RANAP Security Mode Command is sent. The 
authentication procedure (if it is to be performed) can be done before or after sending the UESBI-Iu to the RNC. 

If the RNC does not receive the UESBI-Iu information before the RANAP Security Mode Command, then the 
RNC should assume that no UESBI-Iu information is available for this UE (for example, because the SGSN does 
not support the PUESBINE Feature) (and unless the RNC has already received UESBI-Iu on an existing CS 
domain lu connection). 

4-8) Steps 4 to 8 are as described in TS 23.060. [4] 
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Figure 5.2.8.2-1 : Network Initiated Service Request Procedure 

1-4) Steps 1 to 4 are as described in TS 23.060 [4]. 

The MS sends a Service Request (P-TMSI, RAI, CKSN, Service Type) message to the SGSN. Service Type 
specifies Paging Response. 

5a, b) The SGSN shall send the UESBI-Iu to the RNC before the RANAP Security Mode Command is sent. The 
Authentication procedure (if it is to be performed) can be done before or after sending the UESBl-lu to the RNC. 

If the RNC does not receive the UESBl-lu information before the RANAP Security Mode Command, then the 
RNC should assume that no UESBl-lu information is available for this UE (for example, because the SGSN does 
not support the PUESBINE Feature) (and unless the RNC has already received UESBl-lu on an existing CS 
domain lu connection). 

6-8) Steps 6 to 8 are as described in TS 23.060 [4]. 

5.2.9 Intra- and inter-MSC handover GSM to UMTS 

For the intra-3G_MSC GSM to UMTS handover procedure described in 3GPP TS 23.009 [5], the UESBl-lu shall be 
sent from the 3G_MSC to the target RNS in the lu Relocation Request message. 

The Basic Inter-MSC Handover GSM to UMTS is illustrated in Figme 5.2.9-1 (copied from 3GPP TS 23.009 [5]). 
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Figure 5.2.9-1 GSM to UMTS inter-MSC handover 

GSM to UMTS handover is initiated as described in 3GPP TS 23.009 [5]. 

1 The UESBI-Iu is NOT sent by BSS-A to MSC-A. 

2 MSC-A derives the UESBI-Iu from the IMEISV The UESBI-Iu shall be sent by MSC-A to 3G_MSC-B in the 
MAP_Prepare_Handover request message. 

If 3G_MSC-B did not receive the UESBI-Iu (for example because MSC-A does not support the PUESBINE 
Feature) then 3G_MSC-B shall ignore this fact. 

3 3G_MSC-B shall store the UESBI-Iu in case it is needed for a later inter RNC[/BSS] intra MSC-B handover . 

4 3G_MSC-B shall include the UESBI-Iu in the lu-RELOCATION-REQUEST message sent to the target RNC. 

If the RNC does not receive the UESBI-Iu in the lu-RELOCATION REQUEST message (eg because either 
MSC-A or MSC-B does not support the PUESBINE Feature) then the RNC shall not reject the lu- 
RELOCATION REQUEST because the UESBI-Iu is missing. 

The rest of the steps are as described in 3GPP TS 23.009 [5]. 
For subsequent Inter-MSC handover, MSC-A shall transfer the UESBI-Iu to MSC-B'. 

5.2.1 Inter-MSC handover GSM to GSM 

In the Basic inter-MSC handover procedure (GSM to GSM) described in 3GPP TS 23.009 [5], UESBI-Iu shall be 
transferred from MSC-A to MSC-B. One reason for this is because UESBI-Iu may be needed in the case that there is a 
later inter-system handover from GSM to UMTS under MSC-B. 

The Inter-MSC Handover GSM to GSM is illustrated in Figure 5.2.10-1 (copied from 3GPP TS 23.009 [5]). 
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Figure 5.2.10-1. GSM to GSM inter-MSC handover 

Inter-MSC GSM to GSM handover is initiated as described in 3GPP TS 23.009 [5]. 

1 The UESBI-Iu is NOT sent by BSS-A to MSC-A. 

2 MSC-A derives the UESBI-Iu from the IMEISV. The UESBI-Iu shall be sent by MSC-A to MSC-B in the 
MAP_Prepare_Handover request message. 

If MSC-B did not receive the UESBI-Iu (for example because MSC-A does not support the PUESBINE Feature) 
then MSC-B shall ignore this fact. 

3 MSC-B shall store the UESBI-Iu in case it is needed for a later BSS to RNC intra MSC-B handover. 

[4 If MSC-A supports the transfer of UESBI-Iu on the A interface, then the UESBI-Iu shall be sent to the BSS in 
the Handover Request message.] 

The rest of the steps ai-e as described in 3GPP TS 23.009 [5]. 

For Subsequent Inter-MSC handover, MSC-A shall transfer the UESBI-Iu to MSC-B'. 

5.2.1 1 Inter-MSC handover UMTS to GSM 

In the Basic inter-MSC handover procedure (UMTS to GSM) described in 3GPP TS 23.009 [5], UESBI-Iu shall be 
transferred from MSC-A to MSC-B. This is because UESBI-Iu may be needed in the case that there is a later inter- 
system handover from GSM to UMTS under MSC-B. 

The Inter-MSC Handover UMTS to GSM is illustrated in Figure 5.2.1 1-1 (copied from 3GPP TS 23.009 [5]). 
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Figure 5.2.11-1 UMTS to GSM inter-MSC handover 

UMTS to GSM handover is initiated as described in 3GPP TS 23.009 [5]. 

1 The UESBI-Iu is NOT sent by RNS-A to 3G_MSC-A. 

2 3G_MSC-A derives the UESBI-Iu from the IMEISV. The UESBI-Iu shall be sent by 3G_MSC-A to MSC-B in the 
MAP_Prepare_Handover request message. 

If MSC-B did not receive the UESBI-Iu (for example because 3G_MSC-A does not support the PUESBINE 
Feature) then MSC-B shall ignore this fact. 

3 MSC-B shall store the UESBI-Iu in case it is needed for a later BSS to RNC intra MSC-B handover. 

[4 If 3G_MSC-A supports the transfer of UESBI-Iu on the A interface, then the UESBI-Iu shall be sent to the 
BSS in the Handover Request message.] 

The rest of the steps ai-e as described in 3GPP TS 23.009 [5]. 
For Subsequent Inter-MSC handover, MSC-A shall transfer the UESBI-Iu to MSC-B'. 

5.2.12 Intra- and inter-MSC SRNS relocation UMTS to UMTS 

For the intra-3G_MSC SRNS relocation procedure described in 3GPP TS 23.009 [5], the 3G_MSC-B shall send the 
UESBI-Iu to the target RNS in the lu Relocation Request message. 

The Inter-MSC SRNS relocation procedure is illustrated in Figure 5.2.12-1 (copied from 3GPP TS 23.009) [5]. 
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Figure 5.2.12-1. Inter-MSC SRNS relocation 

Inter-MSC SRNS relocation is initiated as described in 3GPP TS 23.009 [5]. 

1 The UESBI-Iu is NOT sent by RNS-A to 3G_MSC-A. 

2 3G_MSC-A derives the UESBI-Iu from the IMEISV. The UESBI-Iu shall be sent by 3G_MSC-A to 3G_MSC- 
B in the MAP_Prepare_Handover request message. 

If 3G_MSC-B did not receive the UESBI-Iu (for example because 3G_MSC-A does not support the PUESBINE 
Feature) then the 3G_MSC-B shall ignore this fact. 

3 3G_MSC-B shall store the UESBI-Iu in case it is needed for a later inter RNC[/BSS] intra MSC-B handover. 

4 3G_MSC-B shall send the UESBI-Iu to the target RNC in the lu-RELOCATION-REQUEST message. 

If the RNC does not receive the UESBI-Iu in the lu-RELOCATION REQUEST message (eg because either 
3G_MSC-A or 3G_MSC-B does not support the PUESBINE Feature) then the RNC shall not reject the lu- 
RELOCATION REQUEST because the UESBI-Iu is missing. 

The rest of the steps are as described in 3GPP TS 23.009 [5]. 
For Subsequent Inter-MSC handover, MSC-A shall transfer the UESBI-Iu to MSC-B'. 

5.2.13 Intra- and inter-SGSN SRNS relocation (UMTS to UMTS) 

For the intra SGSN SRNS relocation procedure, the SGSN shall send the UESBI-Iu to the target RNS in the lu 
Relocation Request message. The Inter-SGSN SRNS relocation is illustrated in Figure 5.2.13-1 (copied from 3GPP TS 
23.060 [4]). 
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Figure 5.2.13-1. Inter-SGSN SRNS relocation 

Inter-SGSN SRNS relocation is initiated as described in 3GPP TS 23.060 [4]. 

2 The UESBI-Iu is NOT sent by the Source RNC to the old SGSN. 

3 In case of inter-SGSN SRNS relocation, the old SGSN initiates the relocation resource allocation procedure by 
sending a Forward Relocation Request message to the new SGSN. The old SGSN shall include the IMEISV in 
the Forward Relocation Request message. 

If the new SGSN did not receive the IMEISV in the Forward Relocation Request message (for example because 
the old SGSN does not support the PUESBINE Feature), then the new SGSN shall get IMEISV from the MS 
during the Routing Area update procedure (stepl4). In this case the new SGSN shall send the UESBI-Iu to the 
RNC during step 14. 

4 The new SGSN shall use the IMEISV to obtain the UESBI-Iu and then the new SGSN shall send the UESBI-Iu 
in the Relocation Request message to the target RNC. 

If the target RNC did not receive the UESBI-Iu in the Relocation Request message (for example because either 
the old or the new SGSN does not support the PUESBINE Feature) then the RNC shall not reject the lu- 
RELOCATION REQUEST because the UESBI-Iu is missing. 

At point 14, Inter-SGSN Routing Area Update is performed as described in clause 5.2.4. 
The rest of the steps ai-e as described in 3GPP TS 23.060 [4]. 
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5.2.14 Emergency call handling 

5.2.14.1 Mobile with (U)SIM registered in MSC/VLR 

This is handled as in clause 5.2.7.1, above. 

5.2.14.2 Mobile without (U)SIM, or, Mobile with (U)SIM that is not registered in 
MSC/VLR 

The MSCA^LR shall request the IMEISV from the UE using the MM Identification procedure. Once the IMEISV has 
been obtained, the MSC/VLR shall send the UESBI-Iu to SRNC[/BSS]. On the lu interface, the UESBI-Iu shall be sent 
to the SRNC before the RAB Assignment Request message is sent. [If the MSCA'LR supports the transfer of UESBI-Iu 
on the A interface, then the MSC/VLR should send UESBI-Iu as soon as possible (eg to permit the BSS to modify its 
interpretation of the Measurement Reports sent by the UE).] 

5.2.15 Special cases 

The UESBI-Iu is specific to the RRC connection. The RNC shall use all sources of UESBI-Iu and update it with the 
latest received UESBI-Iu. Common ID messages that do not contain UESBI-Iu shall not cause the RNC to change or 
delete any UESBI-Iu that the RNC has already received. 

Note: this requirement is intended to cover situations such as (a) UESBI-Iu is only received from one CN domain, (b) 
the UESBI-Iu received from CS and PS domains are different, (c) etc. 

If UESBI-Iu is received after, instead of before, the RANAP Security Mode Command, then the RNC should use the 
UESBI-Iu for its future actions. 

When the UESBI-Iu is not received for a UE, then the RNC shall assume that the UE has some default capability. This 
default capability is RNC implementation dependent. 



Operational aspects of handling fault information 

Editor's note: text for this clause will be derived from the contents of Annex B once decisions on "Bitmap vs 
IMEISV on lu" and "standardised vs Oh-M" have been made. 
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Annex A (Informative): 

Compatibility with network entities not supporting the 

PUESBINE Feature 

A.1 General 

This annex gives information on the interworking between network entities that support the PUESBINE Feature and 
those that do not. Where this interworking leads to actual requirements on a network entity, then these requirements 
should be documented in the main body of this TS. 

A.2 Inter SGSN relocation 

From an SGSN that does not support the PUESBINE Feature to an SGSN that does support the PUESBINE 
Feature: 

The target RNC will not receive the UESBI-Iu in the Relocation Request message and adopts some generic behaviour. 
The later arrival of UESBI-Iu at RNC is used by the RNC for any future processing for that UE. 

From an SGSN that does support the PUESBINE Feature to an SGSN that does not support the PUESBINE 
Feature: 

The target RNC does not receive the UESBI-Iu, but, this is reasonable considering that the RNC's "default" SGSN does 
not support the PUESBINE Feature. GTP error handling should ensure that reception of the IMEISV is ignored by an 
SGSN that does not support the PUESBINE Feature. 

A.3 Inter SGSN Routing Area Update 

From an SGSN that does not support the PUESBINE Feature to an SGSN that does support the PUESBINE 
Feature: 

If an SGSN that supports the PUESBINE Feature does not receive the IMEISV from the old SGSN, then the new SGSN 
shall get the IMEISV from the MS. 

From an SGSN that does support the PUESBINE Feature to an SGSN that does not support the PUESBINE 
Feature: 

GTP error handling should ensure that reception of the IMEISV is ignored by an SGSN that does not support the 
PUESBINE Feature. 

A.4 lu interface issues 

If UESBI-Iu is not received for a UE, then the RNC assumes that the UE has some default capability. This default 
capability is RNC implementation dependent. 

The RNC can assume that a CN that supports the PUESBINE Feature will deliver the UESBI-Iu before the RANAP 
Security Mode command. 

RANAP error handling should ensure that reception of the UESBI-Iu is ignored by an RNC that does not support the 
PUESBINE Feature. 

A. 5 Gs issues 

If the MSC does not receive the IMEISV in the Gs interface Location Update Request message, then the MSC obtains 
the IMEISV from the UE at the next lu-cs/A interface connection establishment. 
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Gs interface error handling should ensure that reception of the IMEIS V in the Gs interface Location Update Request 
message is ignored by an MSC that does not support the PUESBINE Feature. 

A. 6 Inter-MSC issues 

If the anchor MSC does not pass the UESBI-Iu information to the relay MSC, then the target RNC[/BSS] does not 
receive the UESBI-Iu information. This is handled as an "lu interface issue" (see clause A.4). 

MAP error handling should ensure that reception of the UESBI-Iu is ignored by a relay MSC that does not support the 
PUESBINE Feature. 

A.7 RNC - BSS issues 

If the RNC sends the new Relocation Request Reject cause value then the MSC needs to be able to map this into an 
appropriate A interface cause value. 

Does the RANAP error handling and/or 29.010 provide a default mapping? 

Editor's note: check the CN 4 status of this? 

A interface error handling procedures should ensure that reception of the new Cause value is treated in a backwards 
compatible manner by a BSS that does not support the PUESBINE Feature. 

A. 8 A interface issues 

With regard to the new Handover Reject Cause value, see clause A.7. 

With regard to using the "old BSS to new BSS information" IE to transfer the "don't handover to UMTS flag" between 
BSSs, then existing A interface error handling procedures should ensure that this flag is ignored by a BSS that does not 
support the PUESBINE Feature. 

[If a BSS supports the PUESBINE Feature and the UESBI-Iu is not received for, then the BSS assumes that the UE has 
some default capability. This default capability is BSS implementation dependent.] 

[If UESBI-Iu is sent across the A interface, then existing A interface error handling procedures should ensure that the 
UESBI-Iu is ignored by a BSS that does not support the PUESBINE Feature.] 
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Annex B (informative): 

Operational aspects of handling fault information 

One or both of clauses B.1.1 or B. 1.2 shall be chosen. B.1.1 shall be chosen if the UESBI-Iu mapping from IMEISV 
shall be done with standardised signalling. B.1.2 shall be chosen if the CN entities shall be provisioned with the 
IMEISV to UESBI-Iu mapping with OAM. Then the text needs to be modified to stage 2 parlance and moved to 
clause 6. 

B.1 If UESBI-Iu is BMUEF 

B.1 .1 UESBI-Iu mapping from IMEISV in SGSN and MSC using 
standardised signalling 

The SGSN and MSC derive the UESBI-Iu by mapping from the IMEISV's TACh-SVN. Locally cached databases in the 
SGSN and MSC provide the mapping information. A central database (ie the Faulty IMEISV to BMUEF register) 
should be used to provide the mapping information to the local databases. The central database is interrogated by a local 
database when a not yet known TACh-SVN is to be mapped by the local database. The local database stores the 
mapping information received from the central database. 

The local databases should periodically interrogate the central database to update the mapping information. The period 
is configuration specific. Each signalling message between MSC/SGSN and central database retrieves the BMUEF for 
just one TACh-SVN. 

No functionality is expected on the FIB to MSC/SGSN interface for the FIB to "push" updated BMUEF to the 
MSC/SGSNs. Instead, it shall be possible to trigger the MSC/SGSN to update the locally cached mapping. 

Signalling between the MSC/SGSN and central database (ie the Faulty IMEISV to BMUEF register) shall be based on 
MAP. The FIB may be implemented in an EIR, but it shall be possible to implement the FIB register on a standalone 
node (ie it shall be possible for an operator to deploy the FIB without having to deploy an EIR). The FIB function is 
expected to process many fewer messages than an EIR, and, might have lesser availability requirements than an EIR. 

B.1 .2 UESBI-Iu mapping from IMEISV in SGSN and MSC via 0+M 

Distributed conversion databases in SGSNs and MSCs can be updated using O&M functionality in the network. 
Existing Oh-M procedures can be utilized, so there is no need for further standardisation. 

The Oh-M functionality shall give the operator full control over setting/not setting any of the bits/parameters within the 
BMUEF for each TAC+S VN. This is necessary because the RNC(s) may be supplied by different vendors to the CN 
entities. 

Additional O+M care is needed to ensure that the BMUEF at MSC and SGSN are synchronised (eg when SGSN and 
MSC are supplied by different vendors). 
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